Several people asked for a summary of the information I received concerning my question about segmentation faults. I wasn't very careful about noting which replies were posted to bugtraq and which ones were not, so if I repeat anything here, I'm sorry. For general background, a segmentation fault occurs when a "unprivaledged" process accesses a memory address which is not in its address space or trys to write to memory which has been marked read-only. My question asked how such a scheme was implemented. Specifically, it asked if hardware support was needed to implement such a scheme. I asked the question, because I did not understand how the kernel, being just another process (not hardware), could enforce memory restriction on another process, when atthe time the kernel is not even executing. The answer is, yes, hardware support is required. The cpu has what is called a MMU (Memory Management Uniy). This unit keeps track (in its own private memory?) of virtual memory addressing, memory ownership, and maybe a few other things I'm not aware of. The kernel process is given special privaleges by the CPU/MMU to read and write to these memory tables. It assigns an address space to a process. When that process attempts to access memory it isn't supposed to, the MMU interupts the process, swaps it out to someplace, executes the kernel code (that was previously setup to be by the kernel) to handle the page fault. This normally results in the kernel sending a SIGSEGV to the "malicious process". The exploit script posted with the assembly source was a way of subverting this mechanism in a way I still don't fully understand. I more detailed understanding of the above process specific to the machine and kernel where the bug exists/existed is necessary. With my current understanding and assuming there is no bug in the hardware itself, I don't understand how the exploit script is able to overwrite any kernel memory. If at the point where it trys to overflow some buffer (where is this buffer? In the hardware?) it is stopped by the MMU, how then does it actually get to overwrite kernel memory? Does it actually get to access the memory, THEN the kernel is told that a fault has a occured, and then due to the bug the kernel doesn't clean things up properly? I guess a start might be to know what the asm instructions "restore" and "save" do. But perhaps that is a question for another day, another place. Hope this answers more questions than it asks. :) MikeB